![[TNO-logo]](banner.gif)
Een Control Data 6400 systeem werd in mei 1974 geïnstalleerd in de computerruimte van het toenmalige Physisch Laboratorium. Het Control Data 6600-systeem werd in 1964 ontwikkeld als "supercomputer" door Seymour E.Cray en James E.Thornton. De Control Data 6400 werd in 1965 op de markt gebracht als een eenvoudiger en circa 2.5 maal tragere versie van de 6600. De Control Data 6400 werd voor zijn tweede levensperiode verhuurd aan het Laboratorium.
Het systeem was - voor die tijd - zeer snel en omvatte ook twee tape-units, een kaartlezer - die 1200 kaarten per minuut kon lezen - en een kettingprinter. De architectuur van de genoemde 6000 series computers werd nog al eens gebruikt als model voor studies op het gebied van Petri-nets en optimalisatietechnieken.
Eén van de operators loerde op een kans om een �practical joke� uit te halen met een van de gebruikers. Een groot pak ponskaarten werd alvast verzameld uit de afvalbakken in de ponskamer. En ja hoor, nadat hij zijn kaartenbak had afgegeven raakte de gebruiker in gesprek en lette even niet goed op. In plaats van zijn programma werd een even groot pak afvalkaarten in de bak geplaatst en met de woorden "je programma draait, deze kaarten kunnen wel weg, hé ?" werd de bak op zijn kop gehouden en lag de grond bezaaid met ponskaarten. Het lijdend voorwerp stond wel even te slikken.....
In die tijd werden er ook ponskaarten gemaakt met een afscheurbare (controle)strook. Onder andere de Postgiro maakte daar gebruik van. Om deze korte ponskaarten (51-koloms) te kunnen lezen was er een uitklapbare aanslag op de kaartlezer. Werd dit gebruikt met de standaard 80-koloms ponskaarten dan verfrommelden die daarop spectaculair.... Ook hier kwam de afvalbak wel eens te hulp om een gebruiker witjes te laten wegtrekken.
Als systeemsoftware was naast het Scope 3.4 operating systeem FTN4, ALGOL�60, BASIC, COBOL, SIMSCRIPT, PERT/TIME, SIMULA, APEX en APT IV Automatic Programmed Tools (voor mechanisch construeren oftewel MCAD) aanwezig. Daarnaast werd geprobeerd om een vertaler voor PROSIM, een simulatietaal die ontwikkeld werd door de Technische Hogeschool Delft, aan het werken te krijgen.
Door velen wordt de Control Data 6600-architectuur aangemerkt als het eerste Reduced Instruction Set Computer (RISC).
Het systeem had 8 adresregisters (A-registers) gekoppeld aan 8* 60-bits gegevensregisters (X-registers). Het laden van een nieuwe waarde in vijf van de A-registers (A1-A5) had een "load" vanuit het geheugen tot gevolg, terwijl een nieuwe adreswaarde in het A6 of A7-register een "store" van het overeenkomstige X-register naar het geheugen tot gevolg had. Voor indexering en eenvoudige integers beschikte het systeem over 8* B-registers. Het B0 register was een "read only" register en bevatte de waarde 0. Voorts kende het systeem een beperkte instructieset van circa 60 instructies.
Iedere PP had een eigen geheugen tot zijn beschikking (4096 woorden van 12 bits). Ook de PP�s hadden een beperkte instructieset. Gegevens konden alleen in de "accumulator" of het geheugen bewaard worden. Interlocking van de parallelverwerking was softwarematig geregeld. Een PP-programma zette een "completion bit" of wachtte op het vrijkomen van een "interlock bit" in het centrale geheugen. Feitelijk was er in het systeem slechts één peripheral processing eenheid die door alle "PP�s" (in een barrel) cyclisch "time-shared" gebruikt werd. Hierdoor was interlocking een "unieke" gebeurtenis waarbij verschillende PP-programma�s elkaar niet in de weg konden zitten.
Het kwam wel eens voor dat twee of meer verschillende PP-programma�s ieder in een andere volgorde enkele "interlocking kanalen" aanvroegen. Eens in de vele honderden draaiuren kon het systeem dan in een deadlock komen. Voor de systeemprogrammeurs het moment om drie of vier listings van zo�n drie tot vierhonderd pagina�s naast elkaar te leggen en te bestuderen. Door ervaring konden dit soort problemen vaak in een uur of twee opgelost worden. Overigens werd deze software interlock-techniek eind 80-er jaren door een grote computerleverancier gebracht als nieuwe (!) techniek die symmetrische multi-processing mogelijk maakte, de zogenaamde "spin-lock".
Het centrale geheugen bestond uit circa 65000 woorden kerngeheugen van 60 bits zonder enige vorm van parity- of SecDed-bescherming (circa 480 KiloByte). Om een hogere transportsnelheid van/naar het geheugen te halen was dit onderverdeeld in 8 "banks". Door alle kleine letters en speciale tekens weg te laten (dat was voor wetenschappelijk rekenwerk in die tijd tenslotte niet nodig) konden tekens in "bytes" van 6 bits (10 per woord) opgeslagen worden. Hier lag het begin van het jaar 2000 (Y2K) oftewel millenium probleem.
In 1977 was de behoefte aan geheugen zo gegroeid, dat, na drie dagen wire-wrapping, een extra "geheugenpoot" aan de machine gezet werd. De uitbreiding tot 98 Kwoorden resulteerde voor de gebruikers in een twee keer zo groot geheugen voor de batchjobs.
De kans op foutieve berekeningen ten gevolge van het ontbreken van hardware-parity was kleiner dan die ten gevolge van defecten in de rekeneenheid of de systeemsoftware. Wekelijks was drie uur preventief onderhoud nodig. Dagen dat er 5 of 6 systeemcrashes voorkwamen werden in die tijd normaal gevonden. Speciale programma�s werden geschreven om een "crash"-tape te analyseren op "bitdrops" door deze te vergelijken met de geheugeninhoud van een net fris opgestart systeem. Door uit te rekenen welk bit in welke geheugenbank faalde kon veel tijdwinst geboekt worden bij de reparatie. Om te bewaken dat de rekeneenheid (nog) goed werkte, draaiden er batchjobs mee in het systeem die continu de juiste werking van de CPU en het geheugen controleerden.
Vrijwel ieder jaar kwam er een schijfeenheid bij om de groei van de gebruikersgegevens op te vangen. Vanaf 1975 betrof dit de "dubbel density" schijven (CDC 844-41) met 200 MB
opslagruimte. Files van gebruikers die een maand lang niet gebruikt waren, werden door Operations verwijderd.
Zogenaamde "attach"-jobs waren verboden, doch werden soms door de gebruikers gemaskeerd
als Fortran-programma�s. Operations had als "counter-measure" speciale programma�s die de
attach-jobs konden opsporen.
Zo eens in het jaar gebeurde het dat kogellagers van een van de schijfeenheden uitliepen. Was men er snel genoeg bij, dan kon dat verholpen worden. Het gebeurde ook wel eens dat er een slijpend geluid te horen was. Dit gevolgd door een bruine rookwolk aan oxide-deeltjes die door de lees- en schrijfkoppen uit de schijf geploegd werden.
Omdat het herstellen van het schijfsysteem na een schijfcrash vier tot zes uur nam,
werd een nieuwe schijfeenheid altijd aan
een één dag durende acceptatietest onderworpen.
Omdat de centrale processor niet hoefde te wachten tot een I/O-actie
gereed was konden, meerdere
PP�s gelijktijdig aan het werk gezet worden om de schijf te beschrijven en sequentieel of random te lezen. De ultieme test was het laten heen en weer springen van de koppen tussen eerste en de laatste "cilinder" op het schijvenpakket. Op deze wijze hebben wij eens een schijfeenheid dusdanig in de "eigen frequentie" aangesproken dat die in de loop van de nacht een meter van zijn plaats gewandeld is en door de
channel-kabels weerhouden werd van verdere escapades.
De technici van Control Data waren dan ook niet altijd blij met de "TNO-testen"!
Ten opzichte van collega rekencentra hadden onze schijfeenheden daarna wel een veel hogere
mean-time between failure (MTBF).
Uiteindelijk kon met de eerder genoemde acceptatiejobs voor de schijven tezamen met een iets versnelde systeemklok aangetoond worden dat de timing van de in- en uitvoerkanalen niet geheel was zoals die hoorde te zijn. Het inkorten van een enkele meterslange klokdraad met anderhalve centimeter loste het probleem voorgoed op.
Nu waren er door deze problemen vele CPU-uren verloren gegaan. Dat terwijl er twee grote spoedopdrachten liepen voor het Physisch Laboratorium: simulaties waarop de Tweede Kamer zat te wachten betreffende de verwerving van nieuwe dan wel de conversie van oude tanks en simulaties voor de Koninklijke Marine betreffende berekeningen aan een nieuw type fregat.
In overleg met Control Data Nederland mochten wij twee achtereenvolgende weekeinden van 8 tot 20 uur gebruik maken van de CDC 6600 (machinenummer 1) die bij Control Data in Rijswijk opgesteld stond. De 6600 was 2 tot 2.5 maal zo snel als de 6400. Probleem was de KRONOS-operating systeemomgeving die niet aansloot op wat bij het Physisch Laboratorium TNO in gebruik was. De oplossing was het aanmaken van een eigen mini-operating systeem op twee verwisselbare schijfpakketten. Door slim gebruik te maken van de net nieuwe mogelijkheid om een operationele omgeving te "bevriezen" konden wij het systeem in Rijswijk zeer snel opbrengen. Alleen moesten enige "Equipment Status Entries (EST)" aangepast worden en moesten de "deadstart" schakelaars juist ingesteld worden omdat er in Rijswijk een ander type schijfbesturingseenheden, kanalen en tape-eenheden in gebruik waren. Daarna rekende het systeem binnen 2 minuten verder aan de bevroren rekenklussen.
"Design of a computer: The Control Data 6600" (title in 6000 console display lettering!), J.E.Thornton; Scott, Foresman and Company, 1970; Library of Congres Catalog No. 74-96462
[email protected]
